fraud proof status in ETH L2

I value this very much. Starting next year, I will only publicly mention those L2s that have reached stage 1 or above in blogs, speeches, and other occasions, maybe with a brief grace period for some new and interesting projects.

Whether or not I invest, or whether you are my fren, we must reach the first stage, otherwise no mention.

The 'phase' system of Rollup is a framework for roughly assessing its level of security, from phase 0 to phase 2. In today's mainstream Rollup, only Arbitrum and Optimism have reached phase 1, while the majority of other Optimistic Rollups are still at phase 0.

In this case, some problems have arisen:

Why hasn't any project reached the highest stage 2 since the launch of Optimistic Rollup three years ago?
When can we expect Optimistic Rollup to reach Phase 2?

This article aims to answer these questions by analyzing the fraud proof and challenge mechanism of Optimistic Rollup, and exploring how each project strives to achieve Phase 2. In addition, this article will also look ahead to the future development of Optimistic Rollup and the fraud proof system.

1.2. Comparison between Optimistic Rollup and ZK Rollup

As is well known, Ethereum (ETH) has slow speed and high Money Laundering. Researchers and developers in the Ethereum community have been working hard to solve this problem. After exploring solutions such as Sharding and plasma, the community has finally determined that Rollup is the primary way to achieve scalability. Therefore, Rollups like Arbitrum, Optimism, and zkSync have emerged one after another. According to data from L2Beat, there are currently about 40 Rollups in operation, and other solutions such as Validium and Optimium have adopted the alt-DA solution to achieve higher scalability, with a total of about 41. In addition, it is expected that there will be approximately 80 new Rollup chains launched.

(Current L2 Status | Source:L2Beat）

The core concept of Rollup is to execute transactions off-chain, only submitting transaction data and state roots to the Ethereum blockchain, thus achieving scalability. Users can deposit funds into specific bridge contracts on the Ethereum blockchain, transfer funds to the Rollup, and conduct transactions within the Rollup. Since transaction data is submitted to the Ethereum blockchain and cannot be changed once confirmed without compromising the security of the Ethereum blockchain, people believe that Rollup "inherits the security of the Ethereum blockchain".

But is it true? What if the proposer processing the transaction within the rollup is malicious? A malicious proposer could tamper with Alice's balance, transfer it to their own account, and withdraw it to Ethereum, effectively stealing Alice's funds.

In order to prevent this situation, an additional security mechanism is required when withdrawing from Rollup to ETH mainnet. By providing proof to the ETH mainnet bridge contract, it can be ensured that the withdrawal transaction has been processed correctly and included in the L2 chain before the withdrawal transaction can be completed.

The simplest method, also adopted by every Rollup, is to compare the hash value of the withdrawal transaction with the state root of the Rollup to prove that the withdrawal transaction has been correctly included in the state of the Rollup. This requires submitting the withdrawal transaction and the state root together to the Ethereum bridge contract. Users submit their withdrawal transactions, while validators calculate and submit the state root.

However, if validators of the submitted state root are malicious and submit incorrect state roots, it may endanger the security of user funds. To mitigate this risk, two main mechanisms have been proposed, leading to the differences between Optimistic Rollup and ZK Rollup.

**ZK Rollup **ZK Rollup requires validators not only to submit the state root, but also to provide a ZK proof to verify the correctness of the state root calculation. If validators submit the wrong state root, the ZK proof will not be able to pass the validation of the L1 validation contract, preventing the submission of the malicious state root.
**Optimistic Rollup **Optimistic Rollup allows specified validators to submit the state root without additional guarantees, based on the premise that the submission is honest. However, if the submitted state root is incorrect, anyone can raise a challenge to prevent the state root from being used in the withdrawal process. The challenger must submit evidence to the Ethereum blockchain to prove the state root error, which is called fraud proof (Fraud Proof).

To ensure that attacks such as L1 audit attacks can be safely resolved, the withdrawal time of Optimistic Rollup is usually delayed by about one week to reduce latency.

1.3. Why do we need fraud proof?

Unlike ZK Rollup, the validators of Optimistic Rollup can submit incorrect state roots and attempt to manipulate withdrawal transactions. Fraud proof effectively prevents this, ensuring the security of funds in the bridge contract.

Without a strong fraud proof mechanism, Optimistic Rollup cannot fully inherit the security of Ethereum. For example, in the current Arbitrum's permissioned validators system, if all validators collude, they may steal all funds in the bridging contract. Similarly, on Base and other Rollups based on OP Stack, a single malicious validator may steal funds because an permissionless fault-proof mechanism has not yet been implemented on the Mainnet.

Therefore, fraud proof plays a crucial role in the security of Optimistic Rollup, and any system lacking a complete fraud proof mechanism poses a risk to user assets.

This article will assess the risks faced by various Optimistic Rollup and examine the implementation and pros and cons of their fraud proof mechanism.

1.4. Towards Phase 2: "Removing the Training Wheels"

The fraud proof system has played a key role in helping Optimistic Rollup achieve 'Phase 2'. The phase framework proposed by Vitalik, currently operated by L2Beat, is used to assess the security level of Rollup.

In the Ethereum ecosystem, this phase framework is often likened to learning to ride a bicycle. Phase 0 Rollup relies on the most trust assumptions, likened to a tricycle with training wheels, while Phase 2 Rollup, which fully inherits the security of Ethereum, is likened to a two-wheeled bicycle without training wheels.

The following are the detailed criteria for each stage from Stage 0 to Stage 2:

As mentioned earlier, it is crucial to implement a suitable fraud proof and challenge mechanism for Optimistic Rollup to reach Stage 1 or Stage 2. Considering these criteria, a fraud proof system that meets the requirements of Stage 2 should have the following characteristics:

The system runs well, has no known defects, and has the "1-of-N" feature.
It is a permissionless system, and anyone can submit a testimonial.
If there are vulnerabilities in the proof system, they should be able to be proven on-chain.

In the latter part of this article, we will explore how various protocols attempt to achieve these functions.

2. fraud proof - Concept and Misconceptions

2.1. How is fraud proof implemented?

fraud proof provides on-chain verifiable evidence that the submitted state root is incorrect, indicating that a specific state transition function in L2 was executed improperly. One simple method is to start from the previous confirmed state root and generate proofs for executing all L2 Blocks until the current state root, thus proving that the state root is incorrect. However, this method is expensive and time-consuming.

Therefore, when generating a valid fraud proof, it is necessary to first narrow it down to a specific incorrect state transition, and then generate the proof for that part. Most fraud proof protocols follow this approach.

fraud proof and questioning protocol typically include the following steps:

Validators regularly submit outputs (or declarations) containing L2 state roots to the ETH network.
If validators (质疑者) do not agree with the output, they will raise objections.
The proposer and challenger identify the divergent parts through a process called binary or dissection, and refine them to the instruction level or Block level (ZK Rollup).
The challenger submits fraud proof on-chain to prove the incorrect part. Protocols like Arbitrum and Optimism usually execute suspicious instructions on-chain for verification.
If the fraud proof passes the verification, incorrect output will be removed or replaced. Depending on the protocol being questioned, the proposer may be penalized while the questioner will be rewarded.

2.2. Common Misconception: fraud proof and questioning will not Rollback the chain

It should be noted that even in the event of fraud proof and questioning, the chain will not be rolled back. Fraud proof ensures that the funds in the bridge contract will not be maliciously withdrawn, but does not involve a rollback of incorrect state transitions.

The main reason for not Rollback is that it is unnecessary. When an incorrect state transition occurs in Rollup, the core issue is that malicious actors may steal user funds from the bridge. To prevent this, it is only necessary to ensure that the state root submitted to L1 is correct. This process is unrelated to chain Rollback, as long as the final confirmation of malicious state root is prevented, fraud proof and dispute mechanisms are sufficient.

In addition, if the proposer of the state root and the sorter of the L2 chain blocks are different entities, there is no need for the Rollback mechanism.

Therefore, even if the doubts are successfully resolved, the L2 chain will not be rolled back; only the state root (output or declaration) submitted to L1 will be deleted or replaced. If fraud proof and dispute mechanisms operate normally, the security of user funds bridged can be guaranteed.

2.3. Real Case: Questioning Kroma in April 2024

Through actual challenge cases, it can be seen that the entire Rollup chain will not be rolled back, only the output root will be replaced or deleted. As of now, the only known successful challenge case on the Mainnet occurred in April 2024 for Kroma, which is a hybrid Rollup based on OP Stack and uses ZK fault proofing.

Kroma is an OP Stack based Rollup with its own ZK fault proof and permissionless validators system. On April 1, 2024, there was an issue with the L1 source of Kroma sequencer, resulting in the generation of incorrect Block by the sequencer. Furthermore, validators who observed this situation submitted an incorrect output root. Shortly after the output root was submitted, a total of 12 challengers raised objections to the output.

One of the challengers successfully called the proveFault function and deleted the incorrect output.

The challenger successfully executed the proveFault function | Source:etherscan

This is the first successful challenge case in the history of ETH Rollup Mainnet. It is also the first case to successfully verify and challenge the fault proof in the Mainnet environment, after the launch of the first Optimistic Rollup (Arbitrum) in May 2021, about three years later. For a detailed overview of the challenge, please refer to the article written by Kroma: About the First Successful Challenge on Kroma Mainnet. In this case, the Kroma chain did not undergo a Rollback, but only removed the incorrect output root.

Disclaimer: fraud proof or fault proof?

Fraud proof is also known as fault proof. In particular, the term "fault proof" is used in Optimism and OP Stack chains, while the term "fraud proof" is used in projects such as Arbitrum, Cartesi, and L2Beat.

Considering the above Kroma challenge, it can be inferred that the challenge often stems from a "mistake" rather than a malicious attempt to manipulate the withdrawal. In the above case, the main cause was an L1 client exception observed by Kroma validators. In other words, queries are sometimes triggered simply by bugs or improper patches of validators. In this case, the term "proof of failure" may be more appropriate.

However, a term that better reflects its purpose is 'fraud proof'. All the mechanisms introduced so far, as well as those to be introduced in the future, are aimed at verifying 'fraudulent behavior' that attempts to steal funds within the bridge through malicious outputs.

The key point is that while the aim is to prevent fraud, questioning may actually be triggered by mistakes. In this article, I will use the term 'fraud proof', which is more widely used in the ecosystem.

3. Hacker attack! - Utilizing the fraud proof mechanism

3.1. Designing Economic Disputes protocol

Each Optimistic Rollup implements its own fraud proof and challenge mechanism to protect user funds. The common goal of these mechanisms is to 'keep the protocol secure as long as there is at least one honest participant.' Fraud proof is the proof that the predetermined state transition function has been executed correctly, and through the verification process, it will ultimately result in the victory of honest participants.

However, this is not always the case. In fact, even with honest participants, the protocol can still be at risk. For example, due to the complexity of fraud proof, unexpected vulnerabilities may arise, and malicious participants may gain economic advantages over honest participants due to misaligned incentives, resulting in significant latency in user withdrawals or funds being stolen.

Therefore, designing fraud proof and questioning mechanisms is a very difficult task. In particular, to become a Phase 2 Rollup, the questioning mechanism must be perfect and have countermeasures against various Attack Vectors and vulnerabilities.

In other words, each fraud proof and questioning mechanism needs to consider how to deal with Attack Vector. Without understanding each Attack Vector, it is impossible to understand why the protocol must be designed in this way.

Therefore, in this section, we will first examine the following Attack Vectors and explore how various protocols respond to these attacks:

Due to attacks caused by vulnerabilities in controversial games;
Latency attack, extending the user's withdrawal time beyond 7 days;
Sybil attack that consumes the funds and resources of honest participants;
Attacks triggered by L1 validators review;
Attacks launched using the vulnerabilities in fraud proof Virtual Machine.

Please note that all the Attack Vectors discussed below are publicly known and will not affect the security of any Mainnet.

The following chapters will analyze the various protocols and their respective characteristics as follows:

3.2. Attack Vector #1: Using Economic Dispute Games

Most Optimistic Rollups that implement the fraud proof mechanism require binary search to find the first inconsistent point. The protocol must provide incentives to encourage participants to act honestly, which is very important.

One of the simplest ways to achieve this goal is to have participants stake a certain amount of funds when taking action (Margin). If they are deemed to be malicious, they will be slashingMargin.

From the perspective of game theory, the protocol must ensure that the funds spent by malicious participants for attacks are greater than the funds spent by honest participants for defense. However, this is very difficult to achieve.

The key reason here is that, in the game environment, before the questioning is completed, it is impossible to know in advance who the malicious participants are. In other words, the asserters who submit the output may be malicious, and the questioners who question the output may also be malicious. Therefore, protocol must be designed based on the assumption that either party may be malicious. In addition, due to the possible existence of various Attack Vectors, designing protocol becomes extremely complex.

As each protocol adopts different mechanisms, Attack Vector and the attacker's incentive model corresponding to each method must be defined. In addition, an economic security model must be designed to ensure security even when these models are combined.

This topic is still under discussion. In this section, we will analyze the potential Attack Vector that may occur universally, as well as the incentives for participants in these scenarios. In addition, we will explore how each protocol addresses these attacks and to what extent they limit such incentives.

3.2.1. Attack Vector #1-1: latency Attack

A latency attack refers to a malicious entity that does not aim to steal Rollup funds, but to prevent or delay confirmation of the output on L1. This type of attack can occur in most current Optimistic Rollups, increasing additional latency for withdrawals, causing users to withdraw from L1 for more than a week.

This is slightly different from attacks caused by the scrutiny of L1 validators, which will be discussed later. Scrutiny prevents honest participants from taking any action on the ETH network, allowing malicious state roots to be eventually confirmed. On the other hand, latency attacks can result in the final confirmation of latency state roots even when honest participants actively participate. In this case, user withdrawals may not only be affected by latency but also, if the attacker has more funds than the defender, malicious state roots may be eventually confirmed, resulting in the theft of user funds.

One of the simplest methods to prevent latency attacks is to require participants in the querying system to deposit a certain amount of funds or Margin, and if they are considered to cause latency, the Margin can be slashed.

However, some factors need to be considered. What if the attacker is not afraid of funds being slashed and still tries to launch a latency attack?

This Attack Vector is quite tricky. This is also why Arbitrum's fraud proof system is currently running in a permissioned structure.

The fraud proof mechanism used in Arbitrum One and Arbitrum Classic adopts a fork model. Instead of simply allowing participants to question incorrect claims, each participant submits their own claims that they believe to be correct and attaches a certain amount of funds to consider them as a 'fork' of the chain. These claims can also be seen as checkpoints in the chain state.

Arbitrum's branching model

In Arbitrum Classic, participants will submit their believed correct claims and chain branches, gradually eliminate incorrect chain branches through challenges, and ultimately confirm the correct claims.

However, a single challenge cannot determine who is correct. Two malicious participants may use the wrong method to binary search, defining unrelated points as inconsistent points, thereby excluding the correct statement. Therefore, Arbitrum ensures that challenges continue until no participants stake funds on a specific statement, ensuring that if there is at least one honest participant, the challenge can be successfully resolved.

This can be maliciously exploited for latency attacks. Suppose there are honest participants and N-1 malicious attackers staking funds on the correct assertion, and one attacker staking funds on the incorrect assertion. If the attacker can always submit their transaction before the honest participants, they can initiate a challenge first. In the worst case, if they incorrectly bifurcate, splitting their consistent portion rather than the inconsistent portion, they can submit fraud proof on the incorrect portion. Naturally, this will pass, causing the party staking funds on the correct assertion to fail.

As each query may take up to 7 days, an attacker can extend the latency time of the protocol to 7 * (N-1) days.

Latency attacks on Arbitrum Classic | Source: L2Beat Medium

The issue with this mechanism is that the cost of latency attacks is linearly related to the rise in protocol latency. If attackers find this type of attack profitable, they will want to extend the latency time of the protocol as much as possible, and the total latency time will be directly proportional to the attackers' total funds, which may result in very long withdrawal latency times for users.

In short, a fraud proof protocol that can effectively defend against latency attacks must be designed in such a way that the maximum latency time is limited to a certain range, or the execution cost of latency follows an exponential rise mechanism over time, thereby making the cost of executing an attack greater than the incentive to attack.

3.2.2. Attack Vector #1-2: Sybil attack (resource exhaustion attack)

Another Attack Vector is the Sybil attack (resource exhaustion attack, Whale attack). This occurs when the attacker's funds or computational resources exceed those of the defender. The attacker can continuously submit incorrect output roots or create meaningless challenges, depleting the defender's funds or computational resources. At some point, the defender will exhaust their funds or idle computational resources, rendering them unable to defend, while the attacker will ultimately confirm the incorrect output root and steal the funds.

Usually, the above Attack Vector can occur in unlicensed systems in the following two ways:

Continuously submit incorrect outputs. Suppose the attacker Bob's funds exceed the total of honest participants (defenders) Alice, Charlie, and David. In this case, Bob continuously submits incorrect output roots. Honest participants Alice, Charlie, and David will counter this by paying gas fees and deposits, and at some threshold, the funds of honest participants will be exhausted before Bob's. At this point, Bob submits another incorrect output, and since there are no honest participants with remaining funds in the network, this output will ultimately be finalized without question. In this way, Bob can steal funds from the optimistic rollup.
Submit multiple challenges to the honest output. On the contrary, malicious participants can attack honest participants by submitting multiple challenges. Similarly, the attack will continue until the honest participants run out of funds for gas fees and deposits, and then the malicious attacker will submit incorrect outputs and steal user funds from the bridge.

To prevent such attacks, it is necessary to design the defender's advantage over the attacker reasonably. In all cases, the defender must have sufficient advantage over the attacker. One way to achieve this is to carefully design the collateral; since Sybil attacks are related to the total amount of funds available to each participant, if the collateral is set properly, it should be possible to determine that 'the system is secure when the attacker's total funds do not exceed N times the defender's total funds.'

Another known method to prevent Sybil attacks is to implement a dispute protocol resistant to Sybil. In the next section, we will further introduce Cartesi Dave.

Let's see how each protocol addresses these latency and Sybil attacks through their respective designs.

3.3. Solution #1: A Sound Economic Game of Dispute Resolution

1) Arbitrum BoLD

On the basis of the branch model of Arbitrum Classic, BoLD introduces the following three elements to prevent vulnerabilities from latency attacks:

All to all challenge mechanisms. In BoLD, challenges are no longer pairwise, but instead use a concurrent all-to-all system where all participants can stake funds on the branch they agree with. This prevents the latencyAttack Vector generated by previous pairwise challenges and ensures that multiple independent challenges cannot occur for the same dispute.
Proofs based on correct state computation prevent malicious bisection (historical commitments). The issue in Arbitrum Classic is that malicious participants can deliberately cause latency by bisection in an incorrect way, marking undisputed parts as disputed points. Therefore, BoLD requires submission of proofs to verify that the state root was correctly calculated during the bisection process, together with the state root, to ensure that no malicious bisection occurred.

In BoLD, participants must submit proof and state root during the bifurcation process. This proof verifies whether the current state root is correctly calculated based on the previously submitted state root. If a malicious participant attempts to submit any root unrelated to the previously submitted state root during the bifurcation process, the proof verification will fail, leading to the failure of the bifurcation transaction. This effectively ensures that each claim can only result in one type of bifurcation.

Therefore, if an attacker wants to perform multiple binary partitions on honest statements in BoLD, they must submit multiple statements.

However, generating this proof requires validators to use a considerable amount of computing resources. Internally, generating this proof requires generating a hash for all states in the binary search. In Arbitrum, it is usually estimated that about 270 hashes are needed (approximately 1.18 x 10²¹). To address this issue, BoLD divides challenges into three levels, reducing the number of hashes to be computed to 226 (approximately 6.71 x 10⁷).

(This figure assumes a total of 269 instructions, the actual data may vary)

Limit stake time through the chess clock mechanism.

In the previous Arbitrum Classic, there was no time limit for the duration of the challenge, allowing malicious participants to indefinitely latencyprotocol as long as they had sufficient funds. BoLD has introduced a chess clock mechanism, effectively limiting the duration of the challenge.

Assume that two participants have submitted different claims. Each participant has a timer (chess clock) with a time of 6.4 days. When it is a participant's turn to submit a binary or proof, the timer starts counting down and stops when the participant completes the task.

Since each participant has 6.4 days, the maximum time for a single participant to latency the process is 6.4 days. Therefore, in BoLD, the longest duration of questioning is 12.8 days (in some cases, an additional 2 days when the Security Committee intervenes).

Through these mechanisms, Arbitrum BoLD effectively limits the latency caused by disputes. The maximum duration of a dispute is two weeks, and the maximum additional latency that users may experience is approximately one week.

However, this could be exploited to conduct latency attacks. Malicious participants can create a challenge and collude with L1 validators to review the honest validators on Arbitrum, thereby causing withdrawal latency for Arbitrum users to last up to a week. In this case, users requesting withdrawals during this period may face opportunity costs due to locked funds. Although this is not an attack that directly profits the attacker from the funds, it should still be prevented as it imposes opportunity costs on users. Arbitrum BoLD is addressing this issue by setting the required collateral for creating challenges high enough to deter such attacks.

Arbitrum calculates this amount in the BoLD economic document. The main reason for protocol latency is the review of L1 validators. In the case of a latency attack, the scenario will unfold as follows:

The attacker submits a statement N' that is inconsistent with the existing statement N on Arbitrum before confirming it.
The defender attempted to send a binary transaction, but this operation failed because the L1 validators were reviewing the defender's disputed transaction.
Due to the assumption that the BoLD review cannot last more than 7 days, this may result in a maximum latency of one week for the final confirmation of declaration N.

The attacker's profit comes from the opportunity cost incurred by users who question the withdrawal request. In the worst case scenario, all funds in Arbitrum are requested for withdrawal in one output. The opportunity cost borne by users is calculated as follows, assuming Arbitrum One's TVL is $15.4 billion and APY is 5%.

Opportunity cost=15,400,000 x (1.051/52 - 1) = $14,722,400

Due to the high opportunity cost that may result from incorrect declarations, declarants in BoLD are required to submit a similar amount of collateral. Currently, the collateral required for declaration submission in BoLD is set at 3600 ETH, equivalent to approximately 9.4 million US dollars.

This is done to prevent attackers from causing significant losses to the system through latency. As attackers would lose their collateral in question, they can incur opportunity costs of up to $14.7 million, but would lose approximately $9.4 million in funds. Therefore, BoLD suppresses latency attacks by requiring collateral equal to the worst-case opportunity cost.

However, the 3600 ETH collateral is not set solely due to the latency attack. To defend against Sybil attacks, Arbitrum BoLD can ensure that the system remains secure until the attacker's total funds are 6.5 times that of the defender, and this is the basis for determining the collateral amount of 3600 ETH.

From the perspective of Sybil attacks, the following attack scenarios may occur in Arbitrum BoLD. BoLD's challenge system consists of three levels, and users must lock funds to submit what they believe to be the correct statement.

Assuming an honest participant Alice submits a valid claim for X ETH. Malicious participant Bob, who holds 3600 ETH, can create multiple malicious claims. At this point, Alice needs to lock Y ETH at the underlying level for each of Bob's claims.

In Arbitrum's branching model, locking funds means agreeing to the chain state from genesis to declaration. This feature allows participants to move their staked funds from declaration A to its sub-declarations A' and A''. Therefore, Alice moves her initially staked X ETH to the lower layer, and locks Y ETH for each malicious declaration by Bob.

If Bob's funds are significantly more than Alice's, what will happen? Bob can generate countless malicious claims until Alice's funds are exhausted and cannot continue to be locked. At this moment, Alice will be unable to continue the binary search, allowing Bob to confirm incorrect claims.

Ultimately, the issue boils down to the degree to which defenders should have the upper hand over attackers in the game.

Arbitrum refers to this metric as the resource ratio. It indicates the degree of advantage that honest participants have over malicious participants. This ratio is represented by the ratio of gas fees (G) and collateral amount (S) that each participant must pay, as shown below:

BoLD's challenge system is divided into three levels, ensuring that defenders always have N times the advantage over attackers by maintaining this resource ratio at each level. Arbitrum calculates the amount of collateral required at the top level based on this resource ratio and plots the chart.

(Top-level dispute collateral cost vs. Arbitrum BoLD resource ratio | Source:Desmos

According to the figure, when the resource ratio is 100 times, the top-level required collateral exceeds 1 million ETH (over 4 trillion US dollars). Although a higher resource ratio makes the system more secure against Sybil attacks, the collateral amount becomes so high that almost no one can participate in the system, making it no different from a centralized system with only one validators submitting claims.

Therefore, in BoLD, the resource ratio is set to 6.5 times, so that the top-level collateral is 3600 ETH, and the first and second level collateral are set to 555 ETH and 79 ETH, respectively.

In short, BoLD ensures that defenders have 6.5 times the advantage over attackers by calculating resource ratios and setting collateral amounts to prevent Sybil attacks.

2) Cartesi Dave

Dave from Cartesi first proposed the concept in December 2022 in a paper titled "Non-Permissive Review Championship", earlier than the first White Paper of BoLD. It aims to keep the computing resources and funds of honest participants at an advantage over attackers. Dave's structure is similar to BoLD, with two key features:

Proof of Correct State Calculation (Historical Commitment) to Prevent Malicious Forking.

Similar to BoLD, Dave requires participants to generate proofs during the binary process to demonstrate that they have correctly performed the computation, thereby preventing malicious forms of binary. Therefore, Dave's challenge system is also divided into multiple levels to save the resources of validators.

In the tournament structure, a one-on-one sequential questioning mechanism is adopted.

Dave's questioning is not done all at once, but in the form of a tournament, as shown in the image below.

The figure above shows how doubt is carried out when a malicious attacker submits seven erroneous statements to challenge the network. Due to the nature of historical commitments, honest participants supporting the correct statement (shown in green) are gathered together to form a team. In Dave, they are organized in a tournament format and arranged as shown in the diagram, with each participant engaging in one-on-one challenges. Challenges in the same stage are conducted in parallel, and after a week, when the challenges are completed, the winners will move on to the next stage. In the figure, the team of honest participants must go through three rounds of challenges to win the tournament.

This feature is very effective in preventing Sybil attacks. First, the attacker must create multiple claims to execute a Sybil attack, each of which will significantly consume the attacker's computing resources and funds.

Cartesi's paper proves that, in any situation, the defender always maintains an exponential advantage over the attacker. In other words, Dave ensures that he can defend against Sybil attacks with a logarithmic amount of resources against the attacker. This makes it very difficult to execute a Sybil attack in Dave, so the collateral amount for Dave is set at a minimum of 1 ETH, far below the amount in BoLD.

However, Dave is easily susceptible to latency attacks. Each stage of the tournament consumes one unit of challenge time (one week), so the more malicious claims, the longer the protocol latency. The time required to fully resolve a challenge in Dave can be represented by the following formula:

Td = 7 x log2(1 + NA)(days)

Where NAN_ANA represents the number of malicious assertions. However, Dave's challenge can be composed of multiple levels to effectively generate historical commitments. Here, malicious participants can generate NAN_ANA malicious assertions at each level of challenge, which will increase the total latency time as follows:

Td = 7 x [log2(1 + NA)]L(days)

Among them, LLL represents the number of levels in each objection. If, as shown in the above figure, there are seven malicious claims and L=2, it may take up to 9 weeks to fully resolve the objection, and users will experience an additional 2 months of withdrawal latency. If the number of levels or malicious claims increases, the latency may extend to several months.

Cartesi aims to address this issue using Zero-Knowledge Proof (ZK), detailed discussion of which will be conducted in section 4 'Feasible Improvements'.

3) Optimism Fault Proof (OPFP)

OPFP is an unlicensed questionable protocol, currently in use on the OP Mainnet, with the following characteristics:

Use all-to-all concurrent questioning mechanism of game tree

OPFP allows anyone to submit outputs (root declarations) at any time. Validators who disagree with the submitted outputs can initiate a binary process to challenge them.

OPFP Game Tree and Binary Process Architecture | Source: Optimism File

The binary process is carried out concurrently on the game tree shown in the figure above. The leaves of the tree represent the state of L2, and each Node in the tree corresponds to a state in L2, the rightmost leaf represents the latest state of L2. For example, submitting a claim at Node 1 is equivalent to submitting a state at Node 31.

This structure allows for binary representation. For example, if a validators disagrees with the root declaration (Node 1), they will submit a declaration at Node 2, which corresponds to Node 23 in the tree, as it is the midpoint between Node 16 and Node 31. The submitter of Node 1 will then check the L2 status of Node 23, if in agreement, they will submit Node 6 (Node 27); if not, they will submit Node 4 (Node 19), continuing this process until a divergence is found.

Even if there are multiple binary directions in a game, they can be conducted simultaneously, and anyone can participate in the binary process, not just the output submitter.

OPFP Complete Architecture of Game Tree | Source: Optimism Document

The game tree used in OPFP is a nested structure, with the upper-level tree handling binary at the Block level, and the lower-level subtree handling binary at the instruction level.

Unlike BoLD or Dave, OPFP does not enforce correct bifurcation through historical commitments, as the off-chain/on-chain cost of generating and submitting such commitments is high.

Module-based customizable dispute game Currently, the OP Mainnet has only launched two types of dispute games (non-permitted/permitted). Optimism aims to ultimately introduce various types of dispute games and has implemented the minimum interface to support this goal. By following the designated function names and parameters, custom dispute games can be created.
Restrict questioning time through chess clock

In OPFP, when a dispute occurs, both the proposer and the challenger will be given a clock, which is allocated for binary division. The clock starts timing the opponent each time a statement is proposed. Optimism calls it the 'inherited grandfather's clock'.

Interestingly, each participant is allowed 3.5 days instead of 7 days, which means that if no one questions the output, it will be finalized within 3.5 days.

However, immediate withdrawal is not allowed. After the final determination is made, OPFP has a 3.5-day guardian period during which the Security Committee can intervene and invalidate incorrect outputs if necessary.

The withdrawal process for users in the 'Happy Path' | Source: OP Labs Blog

Based on these mechanisms, OPFP and other optimistic rollups ensure that users can withdraw their funds at least 7 days after submission. However, if there is a dispute, it may take more than 7 days for users to withdraw through the output. The chess clock model of OPFP limits the time each participant can spend on the binary process, but does not strictly limit the total time before dispute resolution.

This raises a question: If there is a dispute on the OPFP, is it possible that a user's withdrawal may be delayed for latency exceeding one week, similar to the situation with BoLD? The answer is 'yes'. Unlike BoLD or Dave, Optimism provides users with options for handling dispute situations, based on the unique characteristics of the protocol.

OPFP operates on the assumption that "participants who submit incorrect declarations will lose their Margin". However, there is a edge case in OPFP that breaks this assumption, known as "free riding declaration". This situation may occur in the following scenarios:

Alice submitted a correct state root statement.
Bob submitted a counterclaim, while Alice took action to defend her original statement.
Bob waited until his clock almost ran out (3.5 days), then questioned his own statement.

At this point, Alice should respond and claim Bob's Margin, but she inherits the remaining time on Bob's clock, which may not be enough for her to refute his claim. Therefore, Bob may avoid losing his Margin by submitting a 'free riding declaration'.

Optimism Fault Proof Hitchhiking Statement | Source:L2Beat

Although this does not prevent questioning from being resolved correctly, it does represent a situation where 'an incorrect statement was submitted without slashingMargin', from the perspective of incentives, this situation should be avoided.

Therefore, if the remaining time of the proposer or challenger is less than 3 hours, OPFP resolves the issue by resetting the clock to 3 hours. This ensures that there is enough time to refute the free-rider claim. However, if no action is taken for more than 3 hours in the next bi-period, the challenge will end.

We can imagine a scenario where this mechanism is used to conduct latency attacks. Assuming honest participant Alice submits a correct output, the challenger's clock starts ticking from the moment Alice submits. Malicious participant Bob waits until 1 second before the challenger's clock expires to submit an incorrect output. At this point, the rules of OPFP will extend Bob's time to 3 hours. Alice will respond, and Bob will continue to take advantage of the additional 3 hours provided for each binary search.

This may raise questions about latency. Bob can latency for a maximum of 3.5 days + 3 hours × the maximum number of binary divisions. The MAX_GAME_DEPTH of OPFP is 73, which means Bob can latency the process for 3.5 days + 3 hours × 36 = 8 days. If Alice takes similar measures to latency challenge, the binary process may take 16 days.

Does this mean that users cannot withdraw within 16 days? Actually, that's not the case because Optimism's withdrawal logic makes this situation invalid. Unlike Arbitrum, which requires withdrawals to be proven to be included in a specific L2 Block, OP Stack uses a storage proof mechanism, and withdrawal requests are recorded in the L2ToL1MessagePasser contract of L2. This means that even if the challenge time for a specific output is long, users can still wait for the next output to complete and withdraw based on the contract storage root contained in that output. Therefore, even if the withdrawal Block they requested is challenged, users do not have to experience long latency because they can use the next output.

However, all of this only holds true if the user acts quickly. In most cases, users may still experience several days of latency. This can be attributed to the withdrawal process in the OP Stack, which primarily consists of the following three steps:

Initiate withdrawal on L2.
Prove the withdrawal transaction on L1, including the withdrawal output.
Wait for a week for the proof of maturity latency, and then finalize the withdrawal transaction to complete the withdrawal.

The key point is that users must wait a week from proving withdrawal to completing the withdrawal. If Alice proves her withdrawal on output B and there is a dispute, she can send another proof for output C and complete the withdrawal after a week. In this case, Alice will only experience latency between output B and output C.

Therefore, users who are unaware of the questioning or respond late may experience up to 9 days of additional withdrawal latency.

In addition, there is an additional latency Attack Vector in OPFP, which means that every output is continuously questioned. In this case, users cannot bypass the latency by proving on the next output, resulting in the entire protocol being affected by latency. OPFP addresses this by requiring participants to stake Margin at each binary level, with the Margin amount increasing exponentially, as shown in the figure below.

OPFP Margin Amount | Source: Optimism Document

In other words, the longer the time it takes for the attacker to question the latency in OPFP, the higher the Margin cost required, because the Margin requirement is rising exponentially, which reduces the incentive to carry out latency attacks over time. In addition, since the output in OPFP can be submitted at any time, it is difficult for the attacker to estimate the resources required for conducting latency attacks. The initial Margin is set at 0.08 ETH, while the total Margin required for comprehensive questioning is as high as ~700 ETH.

In short, OPFP leaves the decision of latency duration to the user in case of a single query and uses exponential Margin requirements to offset latency attacks caused by continuous queries. However, OPFP is vulnerable to Sybil attacks. In OPFP, if the attacker has more funds than the defender, a Sybil attack may occur.

The following Sybil Attack Vectors may exist in OPFP, all of which may lead to the theft of user funds:

The attacker creates multiple doubts, causing the defender to use all funds for Margin and Gas fees.
The attacker continuously submits incorrect outputs, forcing the defender to respond until they exhaust their funds in Margin and Gas fees.

This is possible in OPFP, because throughout the entire questioning process, the total Margin amount required by the attacker and the defender is almost the same, and the resources used by the defender (such as Gas fees or Computing Power) are not significantly less than the attacker.

However, this does not mean that the user funds in the current OP Mainnet are at risk. OPFP is still in phase 1, and the Security Council has the right to correct any improper results. Therefore, even in the event of such an attack, the Security Council can intervene to protect the user funds on the OP Mainnet bridge.

However, in order to move OPFP to phase 2, Optimism must modify the mechanism to ensure that defenders have a greater advantage over attackers. Optimism is preparing for the dispute game V2 to address this issue, and more details will be introduced in section 4 "Feasible Improvements".

4) Kroma ZK Fault Proof (Kroma ZKFP)

Kroma is an L2 based on the OP Stack. Before the introduction of OPFP, it launched a permissionless ZK fault proof system on its Mainnet in September 2023. Kroma ZKFP has similar features to OPFP, but its standout feature is that it generates block-level proofs using ZK and utilizes decomposition instead of binary division, significantly reducing the number of interactions required in the challenge process. The main features of Kroma ZKFP are summarized as follows:

Reduce the number of interactions through ZK and decomposition

Kroma ZKFP allows participants to find the divergence within four interactions. When a challenge is initiated, Kroma ZKFP processes the challenge on 1,800 Blocks, from the previous output to the current output. Unlike binary search, where the range is divided into two halves, in decomposition, the proposer and challenger divide the range into N parts. The process is as follows:

After each participant submits two transactions, they will identify the Block on which they disagree, and challengers can generate a ZK fault proof to demonstrate that the proposer's claim is incorrect. In Kroma ZKFP, the binary timeout is set to 1 hour, while the timeout for ZK proof generation is 8 hours.

Achieve Decentralization of validators through incentive mechanisms

Both BoLD and OPFP offer incentives for challengers, but do not provide specific incentives for output submitters. In fact, anyone who wants to withdraw funds can submit output and become validators. However, it is not practical for users who want to withdraw to operate the validators client themselves, and someone must submit output regularly to keep it active. As this is a resource-intensive task that requires paying gas fees to submit output and operate the validators client, without proper incentives, only a few people may participate as validators, which can lead to centralization and insufficient response in failure scenarios.

To this end, Kroma has modified the OP Stack, allocating half of the gas fees generated on-chain to validators who submit outputs. In addition, Kroma plans to transition this reward mechanism to its native token KRO after the TGE, and aims to introduce a validators system similar to DPoS, allowing ordinary users to contribute to the security and activity of the chain without running their own client.

The Margin amount in Kroma is currently set to 0.2 ETH to ensure that it is greater than the cost of generating ZK proofs and performing binary splitting. This Margin will be transformed into stake of KRO in the future validators system.

Concurrent 1 to 1 Challenge System

To ensure fair and consistent distribution of incentives, Kroma fixes the output submission interval to 1 hour and randomly selects validators from the pre-registered validators collection as proposers. This prevents excessive competition leading to wastage of gas fees and avoids the monopolization of rewards by block builders with transaction ordering privileges.

Due to this mechanism, Kroma ZKFP operates a concurrent 1-to-1 challenge system. Anyone can initiate a challenge when randomly selected validators submit outputs, and the binary is only between the output submitter and the challenger. Multiple challenges can occur simultaneously, and the first challenger to submit a valid ZK proof will win the challenge.

The strict timeout means that even a malicious challenger attempting a latency attack must complete all binary divisions and proof generation within 10 hours. In addition, as challengers are forced to complete all operations within 6 days (excluding a 1-day guardianship period), a general latency attack is not possible in Kroma.

However, if the attacker's funds exceed those of the defender, Kroma ZKFP will still be vulnerable to Sybil attacks, similar to OPFP. In Kroma ZKFP, the scenario of a Sybil attack may be as follows:

The attacker keeps questioning the validity of the output until the submitter's funds are exhausted, at which point the attacker submits a ZK proof to win the challenge.

Similar to OPFP, Kroma ZKFP will delete the corresponding output after a successful challenge. Therefore, if such an attack occurs, the output may be deleted, resulting in a latency of 1 hour for users to withdraw funds. If the attack continues, all honest validators may run out of funds, resulting in the final confirmation of incorrect outputs, allowing attackers to steal user funds.

In addition, Kroma ZKFP is still in phase 0, and its proof system is not yet perfect for the following reasons:

The starting point of binary is based on the final submitted output, not the final confirmed output.

In OPFP, the starting point for binary is usually the last confirmed output about a week ago. However, in Kroma ZKFP, the starting point is the latest submitted output, which was submitted about 1 hour ago, and the binary process is carried out on 1,800 Blocks.

This may allow challengers to win challenges in cases where previous outputs were removed due to challenges. In this case, the binary will be based on the previous output information submitted by the challenger, and if the challenger manipulates this information maliciously, they may win the challenge.

It has not been verified whether each validators questions based on the correct batch data.

Although Kroma ZKFP uses ZK to ensure that if the ZK circuit has no vulnerabilities, it is not possible to eventually confirm an erroneous state transition, Kroma ZKFP does not verify whether the ZK proof generation is based on the correct batch data. This means that even if some transactions are excluded or incorrect transactions are included in the batch, the ZK proof can still pass verification.

Therefore, it is possible to win the challenge by using ZK proofs based on erroneous data, and if a user's withdrawal transaction is excluded from the batch, their withdrawal may experience latency.

However, in practice, the Security Council can intervene to withdraw the results of incorrect doubts or delete invalid outputs, so these Attack Vectors will not affect the funds of Kroma Mainnet users. However, to reach Phase 2, Kroma ZKFP must implement defense mechanisms against these vulnerabilities. Kroma has proposed improvements to address these issues, which will be detailed in Section 4, 'Feasible Improvements'.

3.4 Attack Vector #2: L1 Review

Previously, we mentioned that Rollup inherits the security of Ethereum. This means that if the security of Ethereum is compromised, Rollup will also be affected.

Two scenarios in which the situation of Ethereum may affect the security of Rollup:

**ETH validators review of Rollup fraud proof transactions What happens if ETH validators or builders collude to submit malicious output roots in Optimistic Rollup while reviewing all transactions related to fraud proof? The challenge may not be resolved within the specified deadline, the output will be confirmed, and users' funds may be at risk. This is called weak scrutiny. In the case of Optimistic Rollup, if this scrutiny continues for longer than the specified time (usually 7 days), the user's funds may be at risk.
**Ethereum suffered a 51% attack, resulting in all fraud proof transactions being scrutinized **This situation involves two possible attack paths:

First, an entity can acquire more than 2/3 of the total stake in ETH blockchain, which would allow them to confirm Blocks at will. In this case, the attacker can review fraud proof transactions and even generate them at will.
The second method involves a participant with over 1/3 of the total stake of ETH Ethereum block conducting a "covert" attack. This is described in the research on "Non-attributable censorship attack on fraud-proof-based Layer 2 protocols". In this scenario, an attacker with 1/3 of the ETH stake can prevent the confirmation of any Block they dislike. If the attacker continues to vote for regular Blocks while remaining silent on Blocks containing fraud-proof, they may confirm a malicious state root, thus stealing funds from the Optimistic Rollup. This is known as a non-attributable censorship attack on fraud-proof-based Layer 2 protocols. This type of attack is more difficult to detect than simply obtaining over 2/3 of the stake and controlling all ETH blocks.

These review-based attacks are difficult to deal with at the Rollup level because they occur at the Ethereum protocol layer and require improvements to Ethereum itself. However, Rollup can adopt some strategies during this time.

3.5 Solution #2: 7-day withdrawal latency and semi-automated 51% attack recovery

To address these Attack Vectors, Optimistic Rollup currently implements a 7-day withdrawal latency. The 7-day period was initially proposed by Vitalik, based on the idea that 7 days is "sufficient" to address censorship attacks.

Let's analyze whether the 7-day challenge period of Optimistic Rollup is sufficient to resist censorship attacks, considering two types of censorship: weak censorship and strong censorship attacks.

For the first type of weak censorship, we can use probability calculations to see if 7 days of time gives Optimistic Rollup the ability to resist censorship attacks. This involves calculating the probability of successfully challenging fraud when some validators censor Rollup disputed transactions.

Here, two factors need to be considered:

In order to successfully raise a dispute within 7 days, multiple transactions must be successful.

In most protocols, if only one transaction from an honest participant is included in this week, the challenge will not succeed. Therefore, we need to calculate the probability that all transactions required for submitting fraud proof within 7 days will be included.

It is necessary to reasonably assume the proportion of validators involved in the review. Currently, most ETH block builders (known as centralized) have not been reviewed, considering the proportion of individual stakers on ETH, the chances of collusion among the majority of validators (e.g., 99.9%) for review are almost zero.

Review of the main block builders of ETH | Source: Justin Drake's tweet

Considering these two points, if we assume that 99.5% of the validators (still an overly extreme assumption) participate in the review and calculate the probability of honest participants successfully sending 30 to 40 exchanges' worth of challenging protocols (such as BoLD or OPFP), then in all cases, the probability of success approaches 100%. In addition, with the emergence of future solutions (such as inclusion lists or multiple concurrent proposers, such as BRAID, APS + FOCIL), the ability to resist review may be further enhanced, thereby reducing the risk of losing user funds in Optimistic Rollup due to weak review.

So, is 7 days enough under strong censorship? The 51% attack mentioned earlier can only be resolved through a social fork. It is particularly difficult to detect non-attributable censorship attacks and cannot be prevented by solutions designed for weak censorship, such as inclusion in a list.

There is a proposal to develop a semi-automated 51% attack recovery tool in the client software, based on the structure proposed by Vitalik. Ethereum researchers further developed this review detection solution, divided into two steps:

The light client monitors the memory pool and checks whether the time for some transactions not included in the Block is too long.
If a specific transaction remains in the mempool for one day without being included in a Block, it will trigger the 'Do you agree to initiate a social fork?' button, allowing the community to initiate a hard fork based on this Consensus.

Assuming the tool detects a 51% attack, the next step will be to fork on-chain via social consensus to invalidate the attacker's funds.

In this case, the funds affected by the 51% attack must remain locked until the social fork is completed. A similar situation occurred during The DAO Hard Fork, where the Hacker's funds were locked in the sub-DAO for 27 days until they could withdraw. During this period, the Ethereum community successfully carried out a Hard Fork, preventing the Hacker from cashing out the funds (for more details, please see Vitalik's post on Reddit).

In other words, even in the event of a 51% attack, funds need to remain locked until a social fork is performed. In this case, the 7-day withdrawal period in Optimistic Rollup acts as a buffer. If a social fork is not performed within this week, user funds in Optimistic Rollup may be stolen, withdrawn to a centralized exchange, or mixed through Tornado Cash, making it almost impossible for the funds to be returned to users after the social fork.

In summary, although the 7-day withdrawal period in Optimistic Rollup was originally designed to address weak censorship, the likelihood of weak censorship is small in reality, and this 7-day period serves as a buffer time in the event of strong censorship requiring a social fork.

From this perspective, some criticize OPFP for shortening the deadline to 3.5 days, making it more susceptible to strong scrutiny attacks. However, this criticism is unfounded. As Optimism is still in Phase 1, guardians have enough buffer time to verify the correctness of the state root, and withdrawals can only be made after the additional 3.5-day guardianship period ends. Therefore, even in the event of a strong scrutiny attack, attackers still need to wait for 7 days to withdraw. In addition, attackers must review all transactions related to the query within a full week in order to succeed, as guardians also need to be reviewed to prevent them from terminating confirmation of malicious outputs.

However, the key is that Ethereum (ETH) must ensure that it can handle social forks within 7 days. This means that tools for detecting 51% attacks must be ready, and thorough research and simulations need to be conducted to determine whether a social fork can be implemented within 7 days. Only under this condition can the 7-day withdrawal latency in Optimistic Rollup be considered as effective protection.

3.6 Attack Vector #3: Exploiting vulnerabilities in the fraud proof system

Most of the questions about the protocol are raised by allowing participants to find a specific point (instruction or Block) where their opinions diverge, and then generating proof that another participant's claim is incorrect. The Virtual Machine used to generate this proof is called Fraud Proof Virtual Machine (Fraud Proof VM), and the software used on this Virtual Machine to generate the proof is called a program. Each protocol uses a different Fraud Proof Virtual Machine and program, as follows:

Every fraud proof system is designed to prove that a specific execution result in the EVM is correct on-chain. However, what happens if there are vulnerabilities in the system (whether it's a Virtual Machine or a program)?

This issue can be explored through the Attack Vector discovered by Yoav Weiss in OVM (https://medium.com/infinitism/optimistic-time-travel-6680567f1864). Due to the vulnerability of the Rollback function in OVM, attacks become possible, but it is crucial for the implementation of the attack to create "fraudulent transactions". Fraudulent transactions are transactions that are executed normally on Rollup, but will yield different results when challenged using fraud proof Virtual Machine and programs. Since the fraud proof system should generate the same results as EVM, being able to create fraudulent transactions implies that there are vulnerabilities in the fraud proof system.

Yoav discovered multiple vulnerabilities in the fraud proof system of OVM and was able to simulate this attack by generating fraudulent transactions. One simple attack example he found is that in the OVM's StateManager, the gas cost of Operation Code SSTORE and SLOAD (used for storing and reading state) was incorrectly recorded. This means that any transaction that stores or reads a value in the contract (almost all transactions except simple ETH transfers) will be flagged as a fraudulent transaction in the challenge process, even if it is executed correctly on the Rollup.

In short, if there are vulnerabilities in the system, the correct execution of state changes may be incorrectly marked as invalid during the questioning period, resulting in outputs submitted by honest participants being marked as incorrect.

This is also one of the reasons why OP Mainnet recently changed its fault proof system from an unlicensed mode to a mode where only authorized participants can join. After OPFP was applied to Mainnet, security audits disclosed several vulnerabilities in the fraud proof system (Cannon and op-program) and dispute game challenge protocol. In order to prevent the system from being exploited, Optimism announced on August 17 that it will switch to a permission system.

Of course, exploiting the Virtual Machine vulnerability may not have a significant impact on Rollups in Phase 0 or Phase 1, as the Security Committee can intervene at any time to correct the questionable results. This is a point previously raised by OP Labs. In fact, OP Labs shared its audit framework on the Optimism Forum, outlining the standards for when external audits are needed.

(OP Labs Audit Framework | Source: Optimism Forum)

In this framework, the most recent situation belongs to the fourth quadrant: 'Assistance phase failure proof'. Although these situations are related to the security of the chain, they do not directly affect user funds and are therefore not included in the scope of the audit. This means that even if the vulnerability is exploited, the Security Committee can still rectify the result.

However, since the vulnerabilities have already been identified, it is necessary to address these issues. Optimism has fixed these issues in its Granite network upgrade, allowing OP Mainnet to recover to phase 1.

On the other hand, vulnerabilities in the system can be fatal in Phase 2 of the Rollup. In Phase 2, the Security Council can only intervene in cases where vulnerabilities can be proven on-chain. Since it is almost impossible to prove on-chain that the questioning result is incorrect due to a system vulnerability, if a vulnerability occurs in Phase 2 of the Rollup, users' funds may be at risk.

3.7 Solution #3: Multi-proof

To prevent such issues, it is crucial to conduct a comprehensive audit before deploying the code into production. However, fraud proofVirtual Machine and programs are complex software systems, and the more complex the system, the higher the likelihood of vulnerabilities. Therefore, even with rigorous auditing, vulnerabilities may still occur. We need to explore additional strategies beyond auditing.

One approach is to use multiple proof systems within the same system. During the challenge process, the system not only generates fraud proof using a single system, but can also generate multiple fraud proofs using different Virtual Machines and programs simultaneously, and then compare the results. This will create a system that remains secure even in the event of a vulnerability.

For example, imagine a multi-proof system that simultaneously uses Optimism's Cannon and asterisc ZK fault-proof Virtual Machine (using Risc-V). In case of doubt, the following situations will occur:

If an error output is detected, the challenger generates a challenge and initiates a binary approach.
Once the divergent Block is found through binary search, two sub-games will occur simultaneously:

Cannon's subgame using traditional OPFP method. Use asterisc to generate ZK fault proof subgame.

After completing two games, the two different fraud proofs will be verified.

If both proofs are verified, the challenger wins; if both proofs fail, the challenger loses. However, if one passes and the other fails, it indicates an unexpected vulnerability in a Virtual Machine or program during the proof generation process.

In this case, regulatory entities such as the Security Committee will intervene to adjust the results of the query. This ensures that the system can remain free of vulnerabilities while not violating the condition that the Security Committee can only intervene in the case of vulnerabilities that can be proven on-chain.

This is one of the ongoing efforts to bring Optimism to Phase 2. To support this, OPFP's controversial game involves modular, allowing for the free implementation of multiple fraud proof systems, and defining the minimum interface to support this.

4. Feasible Improvements

In the previous chapters, we discussed the design of the Optimistic Rollup protocol and the potential vulnerabilities in its questioning and fraud proof verification process. This section will discuss the issues and solutions for each protocol, as well as the fraud proof system and the future prospects of Optimistic Rollup.

4.1 Improvement space for each protocol

1) Arbitrum BoLD

BoLD has a robust economic quality protocol, as it limits the maximum protocol latency to one week and ensures effective prevention of Sybil attacks before the attacker's funds exceed the defender's by 6.5 times. However, BoLD has two significant issues:

The advantage of a 6.5x resource ratio is too small for the defender.
The deposit for submitting the root declaration is 3,600 ETH, which is a large amount.

The first issue can be solved through ZK technology. BoLD divides the challenges into multiple levels to reduce the resources required for historical commitment calculation. This can be reduced to a single level by using ZK.

This concept is similar to the BoLD++ proposal by Cartesi's Gabriel. When the challenges are divided into multiple levels, increasing the proportion of resources will result in an exponential rise in the scale of deposits at the highest level. However, when using a single level, it is easier to increase the proportion of resources, making the protocol more resistant to Sybil attacks.

The second issue, which requires a deposit of 3,600 ETH, is even harder to solve. The scale of the BoLD deposit is not only to deal with Sybil attacks, but also to deter latency attacks. The deposit scale is a function of TVL (Total Value Locked), and even with the use of ZK, it cannot be significantly dropped. To address this issue, BoLD is implementing a pooled deposit mechanism that allows multiple participants to share the deposit.

2) Cartesi Dave

Dave effectively countered Sybil attacks through its tournament structure, but as mentioned earlier, it is susceptible to latency attacks. The maximum latency time is a function of the number of malicious declarations NA and the level of stake L, with the formula being: Td = 7 x [log2(1 + NA)]L(days)

If NA = 7 and L = 3, the protocol may face a latency of up to four months, causing significant inconvenience and loss to users, as withdrawals will be subject to latency.

ZK can help alleviate this issue. By fixing the level L to 1 (as in the BoLD++ line), the maximum latency time can be reduced to: 01928374656574839201 Td = 7 x log2(1 + NA)(days)

According to reports, Cartesi is using RISC Zero's ZK technology for this improvement. However, there are still concerns about whether this improvement is sufficient to completely prevent latency attacks. If NA = 7, the protocol may still face additional latency of up to two weeks, while the cost for attackers is only 7 ETH deposit, plus gas fees and off-chain historical commitment costs. For chains with high Lock-up Position value, this penalty may not be sufficient to deter latency attacks.

（Dave: A bold style of questioning mechanism for child doubts | Source: L2Beat Medium）

There is a suggestion to have Dave adopt the BoLD style of questioning mechanism, with 8 participants in each round instead of one-on-one duels, similar to traditional tournaments. In this case, the calculation formula for latency time is:

Td = 7 x log8(1 + NA)(days)

In this structure, the attacker needs to provide at least 64 ETH Margin to challenge the latency exceeding two weeks. The total Margin requirement is 64 ETH, and it requires a significant amount of on-chain and off-chain costs.

However, the drawback of this method is that it weakens the advantage of the defender against Sybil attacks. While BoLD provides a structure where the defender has an N-fold advantage over the attacker, Dave has created a defense mechanism that gives the defender an exponentially greater advantage than the attacker.

In summary, Dave can effectively limit the latency attack vector by using ZK fraud proof. While application structures like BoLD can improve the ability to resist latency attacks, this may result in a drop in advantage for the defender when facing Sybil attacks.

3) Optimism Fault Proof (OPFP)

The drawback of OPFP is that it is susceptible to Sybil attacks, as the cost for attackers and defenders is equal. OP Labs proposed a solution to this issue in Dispute Game V2.

Unlike the original OPFP, which requires participants to submit Margin each time they split, the disputable game V2 only requires participants to submit Margin at the beginning of each split. In addition, the disputable game V2 introduces binary splitting, allowing participants to submit multiple requests at the branching point, thereby reducing the number of interactions in most cases.

(Branch declaration in dispute game V2 | Source: Optimism Specs GitHub)

In the previous OPFP, the vectors of Sybil attacks are:

Create a large number of doubts to exhaust the defender's Margin and Gas fee funds.
Continuously submitting false outputs, forcing the defender to respond and exhaust their resources.

The introduction of branch statements solves both of these vector problems. Firstly, honest participants do not need to submit additional margin during the binary search process, while malicious challengers must submit a deposit for each new challenge they create. If the amount of the deposit is set properly, it becomes unsustainable for attackers to create a large number of challenges.

Secondly, in the dispute game V2, the higher-level Margin amount is larger, so the cost of constantly submitting false outputs is higher for attackers than for defenders.

Therefore, OPFP can effectively counter Sybil attacks by introducing branch declarations in the contentious game V2.

4) Kroma ZK Fault Proof (Kroma ZKFP)

Kroma ZKFP is facing two major challenges: vulnerability to Sybil attacks and an imperfect proof system. To progress to stage 1, Kroma ZKFP needs to address the following two issues:

The starting point of binary search is based on the output of the last submission, not the final confirmed output.
validators have not verified whether the doubt is based on the correct batch data.

Kroma plans to switch from Scroll's Halo2 zkEVM to Succinct SP1 zkVM to address these two issues and move to phase 1.

Kroma is expected to modify its dispute resolution process to align with Optimism's dispute game interface. This adjustment is detailed in Kroma's standards (https://specs.kroma.network/experimental/zk-fault-dipute-game/overview.html) and will allow the starting point of binary to move to the last determined output one week ago, thus solving the first problem.

For the second question, Kroma will use ZK-based trustless inference. The specific working method is as follows:

(Using ZK for Trustless Derivation | Source: Lightscale Notion)

Imagine that we want to prove that a specific L2 Block T is correctly executed. Before generating the ZK proof, we must verify whether the transaction data of Block T is correctly constructed based on the L1 batch data.

Here, Kroma intends to use ZK to verify whether the batch data is correctly extracted from L1. If the data is only obtained through trusted RPC outside the ZK program, it is impossible to confirm whether the batch data has been tampered with. The connectivity ZK proof of generating Blockhash can be used to verify whether the program has accessed the correct Block and extracted batch data, these Blocks range from Block O (the L1 source of L2 Block T) to Block C (the L1 Block at the time of challenge creation). If the challenger constructs L2 Block T based on incorrect batch data, the L1 Blockhash referenced by the challenger to extract batch data will be different from the actual L1 Blockhash containing the batch data (including T1), and it will not be connected to Block C. Therefore, as long as there is no hash conflict, verifying the connectivity of L1 Block through ZK can prove that the challenger has constructed L2 Block from the correct batch data.

Kroma plans to use ZK to verify the accuracy of batch data, which can check the connectivity of Blockhash from L1 Block O to C. If challengers construct L2 Block T based on incorrect batch data, the L1 Blockhash they refer to will be different from the L1 Block containing the correct batch and will not connect to Block C. Since there is no hash conflict, the challenge process can use this method to verify the correct batch data.

With these improvements, Kroma ZKFP will be able to enter Phase 1. However, to reach Phase 2, Kroma needs additional solutions to prevent Sybil attacks, including changing the protocol to All-vs-All and redesigning the Margin mechanism.

4.2. Summary

5. The Future of Fraud Proof

5.1. Phase 2 Rollup - Your funds are safe

As mentioned above, Optimistic Rollups are moving towards Phase 2 development. Arbitrum is making efforts to achieve Phase 2 based on BoLD. The implementation plan of BoLD has been released on the governance forum and has received a lot of support. It has been deployed on the testnet at present. If no major security issues are found, Arbitrum is likely to implement Phase 2 through BoLD by the end of this year.

Optimism is also working to achieve Phase 2. To reach Phase 2 of the OP Mainnet, it is necessary to complete Dispute Game V2 and have multiple proof mechanisms to support multiple proofs. Although the standards are still being perfected, Dispute Game V2 effectively addresses the weaknesses of the existing OPFP, providing strong protection against Sybil attacks, bringing it closer to Phase 2. In addition, various teams, including OP Labs, Succinct, Kroma, and Kakarot, are actively developing multiple proofs, investing a significant amount of research and development resources to create a diverse range of OP Stack proof methods. Therefore, unless significant issues arise, Optimism is also expected to move towards Phase 2 in the first half of next year.

The transition of these two Rollups to Phase 2 may have a significant impact on the Rollup ecosystem. Arbitrum and Optimism each have their own Rollup frameworks, namely Arbitrum Orbit and OP Stack. Their Phase 2 transition means that all Rollups using these frameworks can also transition to Phase 2.

Therefore, from the end of this year to next year, major Rollups with a large user base, such as Arbitrum, OP Mainnet, and Base, are expected to transition to Phase 2, inheriting the full security of Ethereum. This is likely to quell criticisms such as "Rollup is just multisignature" or "Rollup can take away your funds at any time".

5.2. ZK fraud proof is the future

Most discussions of protocols can benefit from implementing ZK fraud proof. For example, applying ZK to Arbitrum BoLD can improve resource ratios, making it more resistant to Sybil attacks, while Cartesi Dave can make it less susceptible to latency attacks. OPFP is also developing ZK in support of multi-proof systems, which could reduce Margin amounts and improve protocol security.

It is worth noting that ZK fraud proof not only means reducing interactions between validators. Less interaction means significantly less resources required by validators, which drops the Margin amount and allows more participants to join the protocol. In addition, this also reduces the maximum possible latency, improving the overall protocol security.

In this way, ZK fraud proof plays a key role in the security and Decentralization of Optimistic Rollup.

5.3. How does ZK Rollup perform? Will fraud proof become weaker?

At this point, some readers may ask: If fraud proof and challenging mechanisms are so complex, will ZK Rollups be a better choice? To some extent, this is correct. In ZK Rollups, reaching phase 2 does not require considering complex economic factors, and users' funds will not face the risk of being stolen in L1 review events, and users can withdraw funds within a few hours.

The transition from Optimistic Rollups to ZK Rollups may be faster than expected. This is because the main drawbacks of ZK Rollups - high proof generation cost and time - are rapidly improving. Recently, Succinct Labs has launched OP Succinct, a ZK version based on OP Stack, which provides an easy-to-start framework for ZK Rollups.

OP Succinct Introduction | Source: Succinct Blog

However, there are still several factors to consider. First is the cost. In OP Succinct, the cost of generating a Block proof is approximately $0.005-$0.01, while the estimated monthly cost of running a prover is between $6,480 and $12,960. If the chain's transactions per second (TPS) are high, these costs may further increase.

(Cost Benchmark for Various Network Proofs | Source: Succinct Blog )

For example, on the Base network of OP Succinct, the average cost of proof generation for each Block is about $0.62. Based on this number, the monthly cost will reach $803,520. This is an additional cost that Optimistic Rollups does not have, even if the ZK cost drops, the operating cost of ZK Rollups will always be higher than that of Optimistic Rollups.

The second consideration is the impact on Decentralization. In ZK Rollups, validators need to run a verifier, which is more difficult and costly than running fraud proof programs in Optimistic Rollups. In addition, due to the slow proof generation time in the ZK system, users cannot verify transactions in real time. Although higher hardware standards can improve proof generation speed to match transaction execution speed, this means that running the verifier requires a high standard computing environment. Ideally, anyone should be able to run a Node to ensure the security of the chain, but ZK has not yet reached this level.

Finally, ZK Rollups, based on highly complex mathematics and cryptography, the complexity of which goes beyond the scope of fraud proof and questioning the protocol. Therefore, extensive testing is required before the ZK system can be safely used in production.

Arbitrum is pursuing a hybrid protocol that combines ZK and Optimistic methods as its ultimate goal. The protocol mainly operates as an Optimistic Rollup, generating ZK proof only when fast withdrawal is needed. This is very useful for scenarios that require rapid rebalancing of funds between chains (such as exchange or cross-chain bridges), and also helps to achieve interoperability between chains.

In short, at present, Optimistic Rollup seems to be effective while adopting ZK as a hybrid solution. However, as the cost and speed of ZK proof generation continue to improve, more Optimistic Rollups may seriously consider switching to ZK in the future.

5.4. Is fraud proof only applicable to Rollup?

We have researched the Optimistic Rollups and fraud proof mechanism of Ethereum. So, what are some other applications of this fraud proof?

Re-stake protocol fraud proof can be actively used in the stake protocol. Taking Eigenlayer as an example, this is a representative re-stake service on the ETH network.

Eigenlayer is a service that allows for the security of ETH blockchain by re-staking. In Eigenlayer, operators can deposit ETH or user's LST based on the delegation contract within Eigenlayer and participate in validation by selecting multiple AVS (Active Verification Services). With Eigenlayer, protocols can easily build AVS and reduce the onboarding cost of initial validators.

Like any other blockchain, AVS rewards successfully verified operators and must punish them when they engage in malicious behavior. This is where fraud proof can be used in the slashing process.

AVS's slashing example | Source:Eigenlayer GitHub**

Taking bridge AVS as an example. The premise of bridge AVS is to correctly transfer the user's funds to the target chain. Any operator who maliciously manipulates the transaction should be subject to slashing. If such manipulation occurs, a challenger who discovers improper conduct can create a dispute with fraud proof in the dispute resolution contract, claiming that the operator has acted improperly in the bridge operation. If the fraud proof is considered valid, AVS can invoke the slashing contract in Eigenlayer to suspend any rewards for the operator.

Although the slashing feature is not yet implemented in Eigenlayer, they recently announced the Shared Security Model (https://www.blog.eigenlayer.xyz/introducing-the-eigenlayer-security-model/), which plans to include the slashing feature in the next version. This will enable fraud proof to be used for slashing.

Data Availability Layer **fraud proof can also be used in the Data Availability (DA) layer. One representative example is the fraud proof proposed and implemented by Celestia. Celestia has a technology that allows light nodes to verify the correct storage of data based on data availability sampling. Let's take a closer look at this concept.

A light client should be able to verify whether a block has been accepted by most (over 67%) validators without downloading all the data of the blockchain. However, it is difficult for the light client to verify the signatures of all validators for each block, and this becomes almost impossible as the number of validators increases.

In this regard, Celestia proposes an interesting concept. In Celestia, even if the majority of validators are malicious, it presents a method that allows a single honest Full Node to inform the light client to reject the faulty Block. This single honest Full Node can ensure its 'honesty' through fraud proof.

There are two types of fraud proof in Celestia:

Fraud proof of state transition

First, the working principle of fraud proof for data is as follows: Celestia allows light nodes to verify whether validators hold the correct data without directly downloading all the data within the blocks. To achieve this, Celestia uses a technique called Data Availability Sampling (DAS).

Celestia data availability sampling | Source: Celestia Documentation

Celestia's validators structure transaction data into a k x k matrix, and then expand it into a 2k x 2k matrix using a technique called 2D Reed-Solomon coding. They then calculate a total of 4k Merkle Roots for each row and column, and include the results of hashing these Merkle Roots further in the Block Header and propagate them.

By Merkle Root information in the Block Header alone, a light node can verify whether Celestia's validators hold the correct data. The light node requests data from random points in a 2k x 2k matrix, while obtaining the corresponding Merkle Roots of the rows and columns from the validators. If these data can be verified with the values in the Block Header, then these validators' data can be trusted.

However, an important consideration arises: what if validators maliciously execute Reed-Solomon encoding? Celestia solves this problem by implementing a mechanism called "bad encoding fraud proof". If Celestia's Full Node discovers incorrect encoding during the Block recovery process, it generates a fraud proof that includes the Block height, the incorrect encoding portion, and the fault proof, and propagates it to the light node. The light node verifies this proof to confirm that the data is indeed encoded incorrectly, thereby ceasing the use of the incorrect data.

In addition, Celestia also proposed a fraud proof mechanism for state transition.

Architecture of Celestia Block | Source: Contribution DAO Blog

Celestia's Block structure includes transaction tracing data at various time intervals. This enables Full Nodes to easily construct fraud proofs, while Light Nodes can detect incorrect state transitions without executing the entire Block. However, due to complexity issues, this mechanism has not yet been implemented on the Celestia Mainnet.

In summary, fraud proof in the data availability layer can filter out incorrect data and state transitions without relying on Consensus.

Machine Learning Artificial intelligence and blockchain became hot topics in 2024, and a lot of research was conducted in this field. One of the most notable aspects is the combination of blockchain and machine learning.

The main reasons for applying machine learning to blockchain are as follows:

Data Reliability: The Block chain manages data in a decentralized manner, and all transactions are recorded openly and transparently. If machine learning models learn from Block chain data, the data source is reliable, reducing the possibility of tampering.
Transparency and Verifiability of the Model: When the machine learning model is executed on-chain, the updates and results of the model are recorded on-chain, making it verifiable. This prevents potential result manipulation or bias that may occur in a centralized environment.

The key factor here is to verify whether the machine learning model has been trained correctly. However, machine learning calculations are highly intensive, making it nearly impossible to fully execute these calculations in the on-chain environment of Block. Therefore, frameworks like opML and zkML have emerged to effectively validate machine learning model training in the Block on-chain environment. opML adopts an optimistic approach to model training, records the results on the Block on-chain, and corrects errors through a questioning mechanism.

Let's take a closer look at the method proposed by ORA, which is a project that provides AI infrastructure on the blockchain. The challenge process of opML is very similar to rollup challenge and consists of the following three key components:

fraud proof Virtual Machine (Fraud Proof VM): This Virtual Machine executes machine learning inference, similar to Arbitrum's WAVM or Optimism's Cannon.
opML Smart Contract: This contract verifies fraud proof, similar to Optimism's MIPS.sol contract.
Verification Game: The validators who initiate the challenge interact with the server through binary search to identify individual erroneous steps in the Virtual Machine, then generate fraud proof for the step and submit it to the opML contract.

Verification Game on ORA opML | Source: ORA Document

Through this fraud proof mechanism, opML leverages the security and trustworthiness of blockchain, while providing a cost-effective environment for training and validating machine learning models.

6. Conclusion

Optimistic Rollup is putting a lot of effort into improving fraud proof and questioning the protocol in order to inherit more security from Ethereum and create a less trusted chain. Arbitrum is expected to reach phase 2 through BoLD by the end of this year, and Optimism is also working towards phase 2, relying on dispute game V2 and multi-proof mechanisms. By next year, users of Optimistic Rollup will be able to interact with the network with higher security without worrying about 'Rollup taking away their funds'. In addition, Vitalik mentioned in his blog that the number of Rollups in phase 1 and above is also expected to increase.

However, there is still room for improvement in each protocol, and many aspects can be strengthened through ZK fraud proof. Kroma has advanced its protocol on this basis, while other protocols such as Arbitrum, Optimism, and Cartesi can also use ZK fraud proof to maintain a more secure and more decentralized approach.

In the field of fraud proof, not only Rollup but also other protocols are investing a lot of research resources. Under the premise of 'only needing one honest participant', combining fraud proof with ZK can help build a trust-minimized Blockchain architecture, and its impact will eventually become a tangible reality for us.

7. Reference materials

(https://l2beat.com/scaling/summary)[L2Beat]

fraud proof战争 | Luca Donnoh at L2Beat

BoLD: Fast and Low-Cost Dispute Resolution

BoLD Economics

Why is the optimistic Rollup challenge period 7 days? | Kelvin Fichter at OP Labs

fraud proof已崩溃 | Gabriel Coutinho de Paula at Cartesi

Optimistic Time Travel | Yoav Weiss

Introduction to the first successful challenge on Kroma Mainnet

Decoding the Progress of Baseline Decentralization | OP Labs

Non-attributable censorship attack on Layer2 protocols based on fraud proof

OP Labs Audit Framework

Untrusted Deduction | Kroma

Introducing OP Succinct: complete validity proof on the OP Stack | Succinct

Eigenlayer GitHub

Celestia Files

Contribution DAO Blog

ORA Document

Declaration:

This article is reproduced from [research.2077], and all copyrights belong to the original author [sm-stack and BTC Penguin]. If you have any objections to this reprint, please contact the Gate Learn team, and they will handle it in a timely manner.
Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
Gate Learn team translates articles into other languages. Unless otherwise specified, copying, distributing, or plagiarizing translated articles is prohibited.